I think you are right. The fingerprints are not set to zero (except when de-serializing from another source). This doesn't affect functionality, false positive rate etc, because it doesn't matter what data is stored initially in this array. But, I would also expect the array to be initialized to zero. This could be done the allocate method (as you have done), or later in the populate method. If done in allocate, then it will be overwritten in deserialize, which I think is not a problem.

So, I'm OK with this patch.

@SirTyson I chose malloc deliberately but I don't object to this PR. I expect that the overhead of calloc over malloc is small.

While I agree that this does not affect false positive rate or correctness, I still think it is a helpful change. In particular, I'm using this library in a blockchain application, where the filter will be part of the ledger and must be bit consistent when constructed on separate nodes. Currently, even with the same initial seed, two nodes will produce different filters at the bit level. While the overall false positive rate is unchanged, I think (but am not an expert on the topic and could be wrong) that two filters constructed with the same initial seed will hit false positives on different keys, which is also not acceptable in a blockchain application.